波音为什么在737 Max 8上犯这样低级错误呢？
一周前，埃塞俄比亚航空一架服役仅 4 个月的波音 737 MAX 8 客机坠毁，机上 149 名乘客和 8 名机组成员全部遇难。这是半年以来坠毁的第二架波音 737 MAX 8飞机。
波音 737 MAX 诞生于波音与空客两家巨头的竞争之中。2010 年，空客开发了A320 neo新机型，并宣称它的新发动机能够提高燃油效率和运营效率。迫于竞争压力，波音 737 飞机不得不更新换代，2011 年 8 月 波音公司董事会批准了 737 MAX 项目。波音宣称，搭载了新发动机的 737 MAX 将会比空客 A320 省油 16%、比 A320 neo 省油 4%，而且航程也会超越 A320 neo。的确，737 MAX优点不少，如官方网站宣称，它也成为最畅销的机型，总订单超过5000架。
成也萧何，败也萧何。
波音737 Max 8之前宣称的优势集中在新发动机上，但空难的导火索可能也来源于新发动机。由于737MAX的新发动机明显大一号，不得不把安装的位置往前移一些位置。因为发动机的位置靠前了，抬头力矩变得很大，使得飞机在飞行时头部容易“翘起来”，而机头翘会容易导致飞机失速坠毁。这很不安全，这时有两种解决方案：
重新设计一下机身，保证飞机的安全；
用打补丁的方式，弥补发动机带来的问题。
第1个选项自然极大增加成本，通过适航标准的历程也会很长，所以波音选择了第二种方式，专门设计了一套自动预防失速系统（automated stall-prevention system），其中当传感器传来的数据显示飞机进入失速姿态（stall）时， MCAS程序会启动并专心干一件事儿——自动压低机头，让飞机俯冲来提升速度。
但是，如果机头降低的幅度非常大时，导致机头无法抽回而坠机。当飞行员发现飞机在俯冲不妙时，会操作飞机拉起机头，而5秒钟后MCAS程序又会把机头按下去、让飞机俯冲；飞行员只好再将机头拉起来，MCAS按下去，飞行员拉起来，MCAS按下去......如此PK下去，最终的结果可想而知。
的确，737 Max 8也有彻底关闭MCAS程序的方法，但那个设置隐藏比较深，需要在触摸屏上进行相对复杂的操作才能完成，这样自然导致有些飞行员可能不熟悉关闭的方法。当飞行员处在紧张的时候，那样的操作估计更不容易完成。虽然驾驶舱有两名飞行员，因为MCAS程序是在飞行员手动操作飞行方式下起作用，而不是在自动巡航时发挥作用。在手动操作飞行方式下，飞行员认为自己完全操控飞机，出现上述情况，可能认为是机械故障的问题，而忽视（甚至不知道）那是MCAS程序在暗暗操作。
看完这个故事，大家也许看出一些问题，例如，飞行员为什么不能第一时间想到MCAS程序在起作用？难道对飞行员的培训不足、还是飞机飞行手册没有突出标出这样的功能特性？其次，下列不合理的设计，在评审时没有被发现吗？
起飞的时候速度偏低、仰头飞行，而且处在手动操作方式，属于正常，这时启动MCAS程序应该很不合适，不是吗？（两起空难都是在飞机起飞后不久发生的）
一旦飞行员采取强制手段拉升飞机，MCAS程序是不是应该自动失效？如同汽车处在自动巡航控制（Cruise Control）模式时，一旦司机踩下刹车，自动巡航控制模式就自动取消。
飞机从抬头被MCAS程序按下时，达到水平飞行而没有到俯冲时，为什么MCAS程序不会根据其它传感器的数据而自动失去作用、把控制权交回给飞行员呢？
除此之外，据说737 Max 8只根据主传感器的数据就判断“有失速危险”，为什么不和另外两个备份的传感器进行数据比较、相互印证？如果两个或三个传感器数据都显示飞机失速，才采取行动，是不是更安全？如果仅仅根据主传感器的数据就作出判断，是不是有较大风险？因为单个传感器自身就可能出问题而传递错误数据。两个传感器或三个两个传感器同时出错的可能性要小多了，特别是出错的数据都一样。
根据关键软件开发与审定——DO-178C标准要求，关键软件的验证更为重要，这就是我经常提到的公式：
Verify = Review + Analysis +Test
test虽是重要的验证活动，但对航空航天的实验很难做，要模仿各种真实场景很困难，而且代价很大。这时评审（review）和分析就显得特别重要。DO-178C标准规定要做充分的评审和分析，例如，关键代码的每一行要被review三遍，详细要求见下列照片显示：
（来源：Leanna Rierson，崔晓峰译，关键软件开发与审定——DO-178C标准实践指南）
在这样的严格评审下，上述问题一般都能发现的。为什么没有发现呢？不能说，Boeing公司不成熟、不优秀，很难相信问题是出自波音公司。但根据某些信息来源，将这部分软件分包给印度的团队开发，设计和代码可能是由不同的团队完成，这样沟通、衔接就容易存在某些问题，代码的评审和设计的评审可能由不同的、相差很远的两个地方（美国和印度）的团队进行的，中间的差异没有被发现。类似当年火星探测器坠毁事件有相似之处，没有完成端到端的验证（评审）、设计和代码实现的一致性严格检查。正所谓，智者千虑必有一失，更何况是上述情况。这只是猜测，真正原因还要等波音自己揭晓，不过，也有朋友说，真正的细节原因可能永远不会公布，就和法航447的真实原因到今天都是未解之谜。
除了评审，分析（analysis）也很重要，DO-178C要求做如下分析：
最坏情况执行时间分析
内存余量分析
链接和内存映像分析
加载分析
中断分析
数学分析
错误和警告分析
分区分析
也有文章谈得没有做好FMEA（Failure Mode and Effect Analysis，失效模式和效果分析）分析。但从目前判断看，设计缺陷是明显的。如果不是设计缺陷，就是代码没有很好实现设计原意和要求。如果在评审设计、代码时，能很好地回答上面提的问题，可能两次空难就不会发生。如果真是这样的评审问题，那这个代价也就太大了。